A. Field of the Invention
The present invention relates to computer networks. More specifically, the invention relates to a method for assigning a public Internet Protocol (“IP”) address from an address server on a network to a Realm Specific Internet Protocol aware host on the network having a private IP address.
B. Description of the Related Art
The IP is an addressing protocol designed to route traffic within a network or between networks. Current versions of IP such as IP version 4 (“Ipv4”) are becoming obsolete because of limited address space. With a 32-bit address-field, it is possible to assign 232 different addresses, which is U.S. Pat. No. 4,294,967,296, or greater than 4 billion possible addresses. A unique IP number is typically assigned to network devices on a network using IP, whether or not the network is connected to the Internet. Most organizations, such as corporations and universities have multiple networks using IP, with multiple network devices assigned an IP address. With the explosive growth of the Internet and intranets, IP addresses using a 32-bit address-field may soon be exhausted. IP version 6 (“IPv6”) proposes the use of a 128-bit address-field for IP addresses. However, a large number of networks including a large number of Internet nodes will still be using older versions for IP with a 32-bit address space for many years to come.
The sharing of a public IP address among multiple hosts is a useful method in cases where a local area network (LAN) is comprised of multiple IP hosts, but possess only a limited number of public IP addresses that reside at a router. Such a network is referred to as a stub network. Each local host on the stub network has only a private (internal) IP address. When communicating amongst themselves, local hosts use their local IP addresses. However, for communications with the public (external) IP network, some form of address mapping/sharing must be implemented in order to allow the local hosts to send/receive packets to/from entities on the external IP network.
Network access systems (“NAS”) generally consist of multiple device subsystems, such as modem cards, which reside in a chassis, and are connected by one or more internal communications systems, such as a communications bus. A larger NAS may consist of multiple chassis connected in a LAN, or some local communications system. Typically, the entire NAS provides one or a few public IP interfaces, usually associated with a router card or subsystem, for communications with the external IP network. Devices on the external IP network can communicate with the NAS through these one or a few interfaces. In certain cases, it is desirable to partition and group the internal NAS resources in such a way to make it appear as multiple, virtual NAS systems to devices on the external IP network. It may even be desirable to make each internal device subsystem individually addressable on the external, public IP network. One way to accomplish this is to implement an IP stack on each internal device subsystem, connect them with an internal LAN, and provide external access by incorporating routing functionality at the NAS's external IP interface. In such a configuration, the internal IP network may also provide the internal communications for the system, or augment some other bus-like system. If the IP addresses of the internal device subsystems are only private, then the internal LAN can be viewed as a stub network. In this case, some form of address mapping/sharing must be implemented to enable the internal, subsystem devices to communicate with the external IP network as IP devices.
Network address translation (“NAT”) has been proposed to extend the lifetime of Internet Protocol (“IP”) version 4 (“IPv4”) and earlier versions of IP by allowing a network to exist behind a set of public IP addresses. See P. Srisureh, “IP Network Address Translator (NAT) Terminology and Considerations,” IETF RFC 2663, August 1999, which is incorporated herein by reference. NAT provides a method for transparent bi-directional communication between a private routing realm, for example a private intranet, and an external routing realm, for example, the Internet. Through use of NAT, addresses of packets sent by the first realm are translated into addresses associated with the second realm. Use of private IP addresses in conjunction with a NAT implementation in a network address server allows the ISP to conserve globally-routable public IP addresses. When a device or node using private addressing desires to communicate with the external world, a private address is translated to a common public IP address used for communication with an external network by a NAT device.
There are several problems associated with using NAT to extend the life of IP. NAT interferes with the end-to-end routing principle of the Internet that recommends that packets flow end-to-end between network devices without changing the contents of any packet along a transmission route. (see e.g., Routing in the Internet, by C. Huitema, Prentice Hall, 1995) Problems with NAT support for end-to-end protocols, especially those that authenticate or encrypt portions of data packets, are particularly well-known. See, e.g., Holdrege et al., “Protocol Complications with the IP Network Address Translator,” Internet Draft <draft-ietf-nat-protocol-complications-01>, June 1999. In applications that transmit IP addresses in packet payloads, NAT requires an application layer gateway to function properly. NAT also creates difficulties when applied to Internet security applications.
Current versions of NAT replace a private network address in a data packet header with an external network address on outbound traffic, and replace an external address in a data packet header with a private network address on inbound traffic. This type of address translation is computationally expensive, causes security problems by preventing certain types of encryption from being used, or breaks a number of existing applications in a network that cannot do NAT (e.g., File Transfer Protocol (“FTP”)).
Current versions of NAT also may not gracefully scale beyond a small network containing a few dozen nodes or devices because of the computational and other resources required. NAT potentially requires support for many different internal network protocols be specifically programmed into a translation mechanism for external protocols in a NAT device such as a NAT router. As is known in the art, a router translates differences between network protocols and routes data packets to an appropriate network node or network device. Computational burdens placed on a NAT router may be significant and degrade network performance, especially if several NAT-enabled stub networks share the same NAT router. In a worst case scenario, a NAT router translates every inbound and outbound data packet.
Realm Specific Internet Protocol (RSIP) has been proposed as an alternative for NAT. See M. Borella et al., “Realm Specific IP: Protocol Specification,” Internet Draft <draft-ietf-nat-rsip-protocol-06>, March 2000 (hereinafter “RSIP-PROTOCOL”), which is incorporated herein by reference. Using RSIP, a host and a gateway negotiate the use of a public IP address and possibly some number of Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports. As is known in the art, Transmission Control Protocol (“TCP”) and User Datagram Protocol (“UDP”) are often used over IP in computer networks. TCP provides a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols that support multi-network applications. UDP provides a transaction oriented datagram protocol, where delivery and duplicate packet protection are not guaranteed. After enabling RSIP in the host, the RSIP-aware host can utilize one or more public IP addresses residing on the RSIP gateway. An important capability of RSIP compared with other methods such as NAT, is that local host devices may terminate IPsec with external IP entities, even while they share the single public address of the LAN router device.
RSIP requires that an application on the host communicate with an application on the RSIP gateway, so the communication link must be configured for IP before this communication occurs. The RSIP client must also know the IP address of the RSIP gateway, so that it can contact the gateway directly. Thus, there is a need in the art for a method by which an RSIP host can determine the IP address of an RSIP gaetway. There is also a need in the art for a process by which a network device and a network server may use RSIP to assign public IP addresses from the server to the network device in order to conserve globally-routable IP addresses.